IBIS Macromodel Task Group

Meeting date: 19 April 2016

Members (asterisk for those attending):
ANSYS:                      * Dan Dvorscak
                            * Curtis Clark
Broadcom (Avago):             Xingdong Dai
                              Bob Miller
Cadence Design Systems:       Ambrish Varma
                              Brad Brim
                              Kumar Keshavan
                              Ken Willis
Cisco:                        Seungyong (Brian) Baek
eASIC:                      * David Banas
                              Marc Kowalski
Ericsson:                     Anders Ekholm
GlobalFoundries:            * Steve Parker
Intel:                        Michael Mirmak
Keysight Technologies:      * Fangyi Rao
                            * Radek Biernacki
                              Ming Yan
Maxim Integrated Products:    Hassan Rafat
Mentor Graphics:              John Angulo
                            * Arpad Muranyi
Micron Technology:          * Randy Wolff
                              Justin Butterfield
QLogic Corp.:                 James Zhou
                              Andy Joy
SiSoft:                     * Walter Katz
                              Todd Westerhoff
                            * Mike LaBonte
Synopsys:                     Rita Horner
Teraspeed Consulting Group:   Scott McMorrow
Teraspeed Labs:             * Bob Ross
TI:                           Alfred Chong


The meeting was led by Arpad Muranyi.

--------------------------------------------------------------------------------
Opens:

- Walter noted that he had prepared a presentation on how referencing affects
  the receiver threshold parameters.

- Arpad noted that Curtis had informed him that he would not be able to attend
  the meeting on April 26th.  Arpad said that we would need someone else to take
  the minutes.  Randy Wolff said he would be able to attend and could take the
  minutes.

-------------
Review of ARs:

- Ambrish to check for a collaborator's feedback on his nearly ready new
  version of the Backchannel proposal.
  - In progress.  Arpad noted that Ambrish was unable to attend the meeting, but
    that he had emailed Arpad a new draft of BIRD 147.  The draft was not quite
    ready for posting, but will be ready soon.

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

- Arpad: Does anyone have any comments or corrections? [none]
- Mike L.: Motion to approve the minutes.
- Walter: Second.
- Arpad: Anyone opposed? [none]

-------------
New Discussion:

New Redriver Flow:
- Fangyi: [sharing his updated "AMI Simulation Flow Round 3" version 3]
  - I've updated the presentation based on the feedback from the last meeting.
  - The changes are not substantial, but they address the comments people made
    with regard to clarifying the presentation.
  - [Slide 4: Conventions (a new slide)]
    - Definitions:
      - "Normal flow" means a channel with no repeaters.
      - "Redriver flow" means the channel has redrivers.
      - Red/Blue/Green boxes:
        - Left side (inputs)
          - Red is the partial or local IR.
          - Blue is the total IR.
        - Right side (outputs)
          - Corresponding IRs returned by Rx Init().
  - [Slides 5 - 10 (the various flows)]
    - Dashed vertical line in the middle, and an arrow indicating left to right
      as the direction from inputs to outputs.
    - Input IRs noted on the left of the dashed line.
    - Output IRs noted on the right of the dashed line.
    - Slide titles modified to avoid confusion about scenarios, for example:
      - "Normal Time Domain Flow: GetWave Tx"  --> changed to -->
        "Normal Time Domain Flow: If Tx has GetWave"
    - Time domain cases more clearly labeled:
      - "Same as current flow" noted wherever appropriate.
      - "Same as current input|output impulse" noted wherever appropriate.
  - Walter has suggested keeping the crosstalk IRs as originally proposed.
  - Walter suggested having the model return just the CTLE IR in the red box
    output.
    - I have not made that modification yet.

- Fangyi: I want to ask Walter and everyone about the parameter used to control
          this new flow.
- Discussion: The group discussed various options, but converged on Walter's
  suggested implementation.  If the model supports this enhanced flow, then the
  new Reserved parameter would appear in the .ami file with:
      - Type: Boolean
      - Usage: In
      - Format: List (false true)
      - Default: false
  If the model does not support the enhanced flow, then the parameter would not
  appear in the .ami file, or, if it did appear, the list would only contain the
  entry false.  Several people asked if we could just use Format Value, but
  Walter noted that Value would only allow one value to be specified by the .ami
  file, it would not allow the user/tool to make a choice.  Radek noted that the
  list parameter might allow the user to make a choice that was inconsistent
  with what the tool could actually do, and that it would fall to the tool to
  make the right choice.  But he still felt the proposed solution was fine.
  Walter noted that since this was a Reserved parameter we could define any
  necessary special handling requirements.  Mike L. suggested that it might be
  bad practice to use one variable to communicate something in two directions.
  Walter stated that the parameter was advertising what the model's capabilities
  were so that the user/tool could make a choice, and thus it was not a two way
  communication.  Fangyi asked if a model could support only the new flow, and
  would therefore have a list containing only the entry true.  Walter thought we
  should make that illegal.  Fangyi expressed some more concern about the user
  having the ability to choose the wrong setting relative to what their tool
  could actually do.  Walter agreed that this could be a source of trouble.
  Radek noted that this feature would be handled subject to the AMI_version
  number, so tools should be able to figure out the proper handling.
  
Referencing and Ground:
- Walter: [sharing his new presentation "Receiver Thresholds Assume
           GND=0.0V=Node 0"]
- Discussion: Walter said that he had put forth the idea that IBIS is a
  specification that defines measurement conditions for a device under test.
  He said others had then pointed out that the [ISSO_xx] keyword descriptions
  did contain some definition of how a device in action (rails fluctuating)
  should behave.  This led him to investigate further.  He found that Node 0 was
  implicitly assumed by the way in which [Receiver Thresholds] specified how
  thresholds should vary when voltages applied to the rails varied.  The
  presentation reviews the "A fully specified single-ended 3.3V CMOS receiver:"
  example found on pages 44 and 45 of the IBIS 6.1 specification.  The example
  is based on device under test conditions with the gc_ref at the [GND Clamp
  Reference] value of 0V and the pc_ref  at the [POWER Clamp Reference] value
  of 3.3V.  Slide 5 of the presentation shows how the thresholds would be
  shifted if pc_ref were instead held at 3.8V.  Slide 6 shows that the same
  threshold values are predicted by the [Receiver Thresholds] computations if
  gc_ref is also increased by 0.5V.  That is, with gc_ref at 0.5V and pc_ref at
  3.8V, the thresholds computed are nonsensical because they should simply be
  shifted by 0.5V since all the rails were shifted by 0.5V.  The [Receiver
  Thresholds] Reference_supply sub-param can only specify one supply rail that
  the thresholds track.  In this example it is the pc_ref rail, so the
  fluctuation in gc_ref is not accounted for and produces this nonsensical
  result.
- Walter: In general, how do you interpret receiver thresholds?
  - This is a classic example of the reference node we are missing throughout
    IBIS.
  - If we can decide how this is supposed to work, then we can do a better job
    in the editorial change to the document.
  - Or, we just say ground is in fact Node 0 is 0.
    - For power aware simulations you would then have to use the ground
      referencing system that Scott noted is an option.
- Arpad: I have to think about this carefully.
  - I want to again comment on the basic [Voltage Range] only case.  That is
    a case where we are only specifying the difference between the pu_ref and
    the pd_ref of the device.  We don't care where it is actually located in
    the universe (whether the ground pin is at 0, 1000V, etc.).
  - This situation is a clear indication to me that what we failed to write down
    in the IBIS spec is that those thresholds were probably referenced to
    something on the die, not outside the die.
- Radek: This is a good catch by Walter.
  - I think the formula is flawed, and we should look at how it should behave.
  - I'm not sure how often it's used, but it is doubtful that calculation is
    right.
  - If everything is shifted, you should get what you expect (threshold properly
    shifted).
- Walter: What Bob has said, correct me if I'm wrong, is that if you have the
  situation with gc_ref at 0.5V and pc_ref at 3.8V, then you have to create
  another [Model] for those conditions and use a [Model Selector] so the user
  can choose between 0 - 3.3V or 0.5 - 3.8V.
- Bob: That's correct if you really want to shift things around by 0.5V.
  - These parameters were defined to map into certain DDR3 and DDR4 parameters.
  - They're defined with the expectation that this is CMOS with gc_ref at 0.
  - Not sure if the shifted case would be realistic.
  - Your points are well taken.
  - All of the reference rails might supply some actual effects in thresholds.
  - But when the modulations get extreme, and 0.5V at the gc_ref might be
    extreme, then that shouldn't be realistic in real designs.
- Radek: If properly defined, that formula could have included the differences
         in both rails when they happen.  But it doesn't.
- Bob: We have an existing syntax.  It has been used.
  - What you're illustrating is what an EDA tool will do with this data if it
    externally drives the buffer with a different voltage.
  - In your case, if the buffer is truly shifted then the 1.5V threshold will
    become 2.0V.  The EDA tool can sort that out.
- Walter: My point in all of this:
  - Here's another place where we make an assumption that ground is Node 0.
  - It's okay to say that for a DUT.
  - As soon as you're doing a power aware simulation and the ground node is
    floating then you cannot use any IBIS thresholds reliably.
  - The easy way out is to accept that IBIS is consistent if you're in a ground
    referenced system.
    - You just supply 0V wherever you have a gc_ref.
    - Simulation is really only modulating supply voltages like pc_ref.
    - The implication for interconnect is that it becomes okay to use Node 0 as
      the reference node for w-lines and touchstone files.
  - As soon as you get away from that and have floating gc_ref, do we just
    leave it up to the EDA tool to make logical sense out of it then?
  - Randy probably has the most experience with power aware simulations.
    - At one point a while ago his models only did power distribution, not
      ground.  I'm not sure if it was for some of these reasons.
- Randy: If we do anything with s-parameters then ground is the reference for
         everything.
  - For anything with s-parameters the ground distribution is wrapped up into
    power and signal models.
  - For the older style RLC models we usually had ground parasitics included.
- Walter: I don't know how power aware simulations were done with RLC models.
- Randy: If you've got the parasitics for power and ground and all the coupling
         between them and you get everything referenced properly then it's ok.
- Bob: When we make assumptions that the supply has changed, we have to
       distinguish whether the change is due to purposefully resetting the
       voltage (DC supply change) or whether we are dealing with ripples.
  - I'm assuming DC changes, but I'm questioning whether an 0.5V shift is
    realistic as a purposefully applied change.
- Walter: We are talking about GHz devices.
  - Power distribution tends to be 1 or 2 orders of magnitude lower frequency.
  - So one could have fluctuations on the power rail that instantaneously look
    like DC to the device.
  - So the power rail could look like it had a DC half volt shift as far as
    the part is concerned.
  - If you have a wide data bus and happen to be sending obnoxious patterns you
    could be drawing from the supply at a much lower frequency than your data
    rate and induce large swings in the supply.
  - Memories are not that bad because you only have 4 or 5 drivers (DQ and DQS).
  - On a controller with 128 bit wide DQ, with weird patterns I'm not sure what
    kind of power distribution values one could have in reality.  Are the
    ripples mV or tens of mV or hundreds of mV?
- Randy: You could see 100mV, that's not out of the question.
  - You supply that current instantaneously from the on-die decoupling when
    you have a high current demand, and your voltage will drop with that spike
    of current needed to charge up that capacitance.
- Walter: People designing packages will want to dissect this carefully.
  - People who design systems will take all this power supply noise and stick it
    into the margins on their device and not worry about power aware
    simulations.
  - People try to isolate these detailed simulations from the end users.
- Bob: If this is a dynamic voltage shift at significantly lower frequency, then
       one can't use a [Model Selector] to switch in alternative models.
  - The [Model] may fail if some switching occurs outside the thresholds because
    of all of the modulation.
- Walter: The question is, can the EDA tool dynamically change the thresholds
          properly?
  - What we do in this situation is we never use absolute voltages.  They are
    always relative to the local supplies.  We understand how to do that.
  - Do we have to have IBIS tell EDA tools how to do that?
- Bob: I don't know.
  - Are we overreaching, especially when we deal with ground supply modulations?
  - We have issues with standard Vinl and Vinh for CMOS.
    - CMOS supports both bipolar thresholds and the approx. 70% and 30%.
    - One I/O buffer input can support two different rules that are
      incompatible.
    - For example, if it's 0.8V and 2.0V for bipolar but it's a CMOS technology
      then that remains relatively fixed whether or not the + or - VCC changes
      10%, but it might be shifted based on the ground reference.
    - For CMOS it's spread between 30 and 70%
    - I'm not sure how much effort we should put into this.  It's already pretty
      complex, and it's supposed to mimic what's in a data sheet.
    - D.C. Sessions, when he was active in the DDR committees, proposed some of
      this stuff based on the JEDEC committee at that time.
- Arpad: We are over time now.
  - This is a good summary.  We need to think it through carefully.
  - We need to come up with a recommendation on how we proceed and what we fix.
- Walter: Michael Mirmak is going to propose a paragraph to be put at the
          beginning of IBIS to address this.  Maybe that will nicely cover this
          so we don't have to make editorial changes everywhere.
- Arpad: Is he aware of the contents of the presentation you made today?
  - Will his text handle what you've discovered here?
- Mike L.: We can bring this up in the editorial group on Friday.
- Arpad: Thank you all for joining.

-------------
Next meeting: 26 April 2016 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
